1. Field of the Invention
The present invention relates to a wireless communications network. In particular, the present invention discloses a method for determining when a packet data convergence protocol (PDCP) sequence number synchronization procedure should be performed.
2. Description of the Prior Art
Please refer to FIG. 1. FIG. 1 is a block diagram of a wireless communications network 10, as defined by the 3rd Generation Partnership Project (3GPP) specifications 3GPP TS 25.322 V3.10.0 “RLC Protocol Specification”, 3GPP TS 25.331 V3.10.0 “Radio Resource Control (RRC) Specification”, and 3GPP TS 25.303 V3.11.0 “Interlayer procedures in Connected Mode”, which are included herein by reference. The wireless communications network 10 comprises a plurality of radio network subsystems (RNSs) 20 in communications with a core network (CN) 30. The plurality of RNSs 20 is termed a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network, or UTRAN for short. Each RNS 20 comprises one radio network controller (RNC) 22 that is in communications with a plurality of Node Bs 24. Each Node B 24 is a transceiver, which is adapted to send and receive wireless signals. In particular, the wireless communications network 10 assigns a mobile unit 40 (generally termed a “UE” for User Equipment) to a particular RNS 20, which is then termed the serving RNS (SRNS) 20s of the UE 40. Data destined for the UE 40 is sent by the CN 30 to the SRNS 20s. This data is in the form of service data units (SDUs) 28 that are held by the RNC 22 of the SRNS 20s pending transmittal by one of the Node Bs 24. The RNC 22 selects a Node B 24 that is best able to accurately transmit the SDUs 28 to the UE 40. Such a selection will depend, for example, upon the location of the UE 40 within the domain of the SRNS 20s. The UE 40 broadcasts SDUs 48 to the wireless communications network 10, which are then picked up by the SRNS 20s and forwarded to the CN 30. Occasionally, the UE 40 may move close to the domain of another RNS 20, which is termed a drift RNS (DRNS) 20d. A Node B 24 of the DRNS 20d may pick up the signal transmitted by the UE 40. The RNC 22 of the DRNS 20d forwards the received signal to the SRNS 20s. The SRNS 20s uses this forwarded signal from the DRNS 20d, plus the corresponding signals from its own Node Bs 24 to generate a combined signal that is then decoded and finally processed into SDUs 28. The SRNS 20s then forwards these received SDUs 28 to the CN 30. Consequently, all communications between the UE 40 and the CN 30 must pass through the SRNS 20s. 
Please refer to FIG. 2 in conjunction with FIG. 1. FIG. 2 is a simple block diagram of the UMTS radio interface protocol architecture. Communications between the UE 40 and the UTRAN 20u is effected through a multi-layered communications protocol that includes a layer 1, a layer 2 and a layer 3, which together provide transport for a signaling plane (C-plane) 92 and a user plane (U-plane) 94. Layer 1 is the physical layer 60, and in the UTRAN 20u is responsible for combining signals received from the DRNS 20d and SRNS 20s. Layer 2 includes a packet data convergence protocol (PDCP) layer 70, a Radio Link Control (RLC) layer 72, and a Medium Access Control (MAC) layer 74. Layer 3 includes a Radio Resource Control (RRC) layer 80. The U-plane 94 handles user data transport between the UE 40 and the UTRAN 20u, whereas the C-plane 92 handles transport for signaling data between the UE 40 and the UTRAN 20u. The RRC 80 sets up and configures all channels between the UTRAN 20u and the UE 40. The PDCP layer 22 provides header compression for Service Data Units (SDUs) received from the U-plane 94 to increase bandwidth utilization efficiency. The RLC layer 72 provides segmentation and concatenation of PDCP 70 SDUs and RRC 80 SDUs into RLC protocol data units (RLC PDUs), and under acknowledged mode (AM) transfers, can provide upper layers (such as the PDCP layer 70 or the RRC layer 80) with a confirmation that RLC PDUs have been successfully transmitted and received between the UTRAN 20u and the UE 40. The MAC layer 74 provides scheduling and multiplexing of RLC PDUs onto the transport channel, interfacing with the physical layer 60.
Before proceeding, it is worth taking note of terminology used in the following. An SDU is any packet that is received from an upper layer or passed to an upper layer, whereas a PDU is a packet generated by a layer and passed on to a lower layer or received from a lower layer. Hence, a PDCP PDU is an RLC SDU. Similarly, an RLC PDU is a MAC SDU, and so forth. As such, whether a packet is termed a “PDU” or an “SDU” will depend upon the point of view of the layer being considered. In general, each layer will add information, typically in the form of a header, to SDU data to generate a PDU.
Each PDCP PDU generated by the PDCP layer 70 in response to an SDU received from the U-plane 94 is incrementally assigned a 16-bit sequence number (SN) by the PDCP layer 70 if a so-called lossless property is configured for the connection. That is, each sequentially successive PDCP PDU generated by the PDCP layer 70 is assigned an incrementally higher SN. For example, at a given instant in a stream of PDCP PDUs, a first PDCP PDU may be assigned an SN of 62 by the PDCP layer 70. A second PDCP PDU generated immediately after the first PDCP PDU would thus be assigned an SN of 63, and so on. When a PDCP entity is first set-up, the first PDCP PDU of the entity has an SN of zero. The SNs are not actually a part of the PDCP PDUs, but are internally maintained by the PDCP layer 70. The PDCP PDUs are then delivered to the RLC layer 72 for transmission. Since bandwidth is to be maximized by the compression of the U-plane SDU headers, each PDCP PDU should, ideally, be smaller in size than its corresponding U-plane SDU. To ensure that this is indeed the case, the PDCP headers should be kept as small as possible, and to provide for this, PDCP SNs are generally not transmitted in their associated PDCP PDUs. Similarly, each PDCP PDU received from the RLC layer 72 is incrementally assigned an SN by the PDCP layer 70. Hence, two unique sets of PDCP SNs exist: one for PDCP PDUs received from the RLC layer 72, and another for PDCP PDUs generated from U-plane 94 SDUs.
As the UE 40 moves closer towards the domain of the DRNS 20d, a decision is eventually made by the wireless network 10 to place the UE 40 under the DRNS 20d, and a transfer process is enacted. This process is termed an SRNS relocation procedure, and under certain transport modes is a lossless procedure. Lossless means that no PDCP SDUs 28, 48 are lost during the relocation procedure. Please refer to FIG. 3 in conjunction with FIGS. 1 and 2. FIG. 3 is a block diagram of the UE 40 undergoing a lossless SRNS relocation procedure. The DRNS 20d becomes a target RNS (TRNS) 20t. After completion of the relocation procedure, the TRNS 20t will serve as the new SRNS 20s for the UE 40. In order for the TRNS 20t to properly take up its job as the new SRNS 20s for the UE 40, the current SRNS 20s must forward key information to the TRNS 20t. Please refer to FIG. 4 in conjunction with FIGS. 2 and 3. FIG. 4 is a message sequence chart for the prior art lossless SRNS relocation procedure. The SRNS 20s sends forwarding information 50 to the TRNS 20t. This forwarding information includes a downlink sending sequence number (DL Send_SN) 52, an uplink receiving sequence number (UL Receive_SN) 54, and all unconfirmed PDCP SDUs 28. The multi-layered communications protocol used by both the SRNS 20s and the UE 40 enables the UE 40 to confirm those PDCP PDUs transmitted by the SRNS 20s that are successfully received by the UE 40. Any PDCP PDUs not explicitly confirmed as received by the UE 40 are termed unconfirmed PDCP PDUs. As each PDCP SDU 28 has a corresponding PDCP PDU, an unconfirmed PDCP PDU generally means that there is a corresponding unconfirmed PDCP SDU 28. These unconfirmed PDCP SDUs 28 are forwarded by the SRNS 20s to the TRNS 20t. The DL Send_SN 52 is the value of the SN associated with the sequentially earliest unconfirmed PDCP SDU. As the SNs are not explicitly carried in the PDCP PDUs, this enables the PDCP layer 70 in the TRNS 20t to properly associate an SN for the corresponding PDCP PDU of each forwarded PDCP SDU 28. The UL Receive_SN 54 is the value of the SN associated with a PDCP SDU that the SRNS 20s next expects to receive from the UE 40. This enables the TRNS 20t to properly associate an SN for each PDCP SDU subsequently received from the UE 40. The TRNS 20t sends the UL Receive_SN 54 to the UE 40. From this, the UE 40 can determine which PDCP SDUs to begin sending to the TRNS 20s under its guise as the new SRNS 20s. The UE 40 sends a downlink receiving sequence number (DL Receive_SN) 58 to the TRNS 20s. The DL Receive_SN 58 holds the value of the SN of the next PDCP SDU that the UE 40 is expecting to receive from the TRNS 20t. From this, the TRNS 20t can learn which of the forwarded unconfirmed PDCP SDUs 28 to begin sending to the UE 40. Consider, as an example, a situation in which the SRNS 20s has sent PDCP PDUs, each of which has a corresponding PDCP SDU, to the UE 40 having associated SNs running from 0 to 99. We may further assume that, of these 100 PDCP PDUs sent, only those with SNs running from 0 to 50 were confirmed by the UE 40. Consequently, there are unconfirmed PDCP PDUs with SNs running from 51 to 99, each of which has a corresponding unconfirmed PDCP SDU 28. Also, the SRNS 20s has received 200 PDCP PDUs, each of which has a corresponding PDCP SDU, from the UE 40, with SNs running from 0 to 199. In the SRNS relocation procedure, the PDCP SDUs 28 with associated SNs running from 51 to 99 are forwarded by the SRNS 20s to the TRNS 20t. The DL Send_SN 52 would have a value of 51, and the UL Receive_SN 54 would have a value of 200. The DL Receive_SN 58 will hold a value that is between 51 and 100, depending on how many of the unconfirmed PDCP PDUs were actually received by the UE 40, but not yet confirmed. If, for example, the DL Receive_SN 58 holds a value of 90, then the TRNS 20t knows that it may discard the forwarded PDCP SDUs 28 that have associated SNs that run from 51 to 89, and will begin transmitting those forwarded PDCP SDUs 28 with associated SNs that are from 90 and above. Although it should not happen, it is possible that the DL Receive_SN 58 will either be sequentially before the DL Send_SN 52 or sequentially after the SN associated with the sequentially last forwarded PDCP SDU 28. Similarly, it is possible for the UL Receive_SN 54 to be sequentially before the last PDCP PDU that that UE 40 considered confirmed as successfully transmitted, or sequentially after the SN of the PDCP PDU that the UE 40 next expects to send to the UTRAN 20u. Any such occurrence of the above means that the SNs maintained by the RNC 22 of the SRNS 20s are out of synchronization with corresponding SNs maintained by the UE 40, and is herein termed a “next expected UL/DL Receive PDCP sequence number invalidity event”. A PDCP sequence number synchronization procedure is thus enacted by the TRNS 20t, or by the UE 40, depending upon which device detects the next expected UL/DL Receive PDCP sequence number invalidity event. During the PDCP sequence number synchronization procedure (and assuming for the sake of example that it is the TRNS 20t that has detected the next expected UL/DL Receive PDCP sequence number invalidity event), the TRNS 20t transmits a PDCP PDU that explicitly containsits associated SN in its PDCP header, with the data region of this PDCP PDU corresponding to the sequentially earliest forwarded PDCP SDU 28. This PDU is termed a PDCP SeqNum PDU. Once the UE 40 has confirmed this PDCP SeqNum PDU (by way of the RLC layer 72), the TRNS 20t considers the PDCP sequence number synchronization procedure completed.
The primary purpose of having PDCP PDU SNs is to support lossless SRNS relocation, as discussed above. Un-synchronization of PDCP SNs between two PDCP entities (i.e., the UE 40 and the UTRAN 20u) can lead to PDCP PDU loss. The PDCP sequence number synchronization procedure as discussed above avoids such loss. In all cases in the prior art, it is the RRC layer 80, in either the UTRAN 20u or the UE 40, that instructs the PDCP layer 70 to perform the PDCP sequence number synchronization procedure. The prior art notes three cases in which the RRC layer 80 should cause a PDCP sequence number synchronization procedure to occur:
1) During an RLC reset procedure.
2) During a Radio Bearer reconfiguration procedure.
3) During a lossless SRNS relocation when a next expected UL/DL Receive PDCP sequence number invalidity event is detected between the sequence numbers of the two PDCP entities.
Under certain conditions, the Radio Bearer reconfiguration procedure will not lead to loss of PDCP PDUs. Nevertheless, the prior art protocol insists that a PDCP sequence number synchronization procedure be performed. This is a waste of radio resources, as it forces the unnecessary inclusion of the 16-bit PDCP sequence number into the transmitted PDCP PDUs. Secondly, when the Radio Bearer reconfiguration procedure is combined with the SRNS Relocation procedure, the prior art further insists that the PDCP sequence number synchronization procedure be performed, even if no next expected UL/DL Receive PDCP sequence number invalidity event has been detected. Again, this wastes radio resources. Finally, there are other RRC procedures besides the Radio Bearer reconfiguration procedure that can lead to loss of PDCP PDUs, and which are unaccounted for in the prior art. This can undermine the entire lossless SRNS Relocation procedure of the prior art, if these RRC procedures are not performed in combination with an SRNS Relocation procedure.